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1 DETAILED ACTION 

2 

3 This action is in response to the communication filed on 4/7/2006. 

4 

5 All objections and rejections not set forth below have been withdrawn. 

6 
7 
8 

9 Specification 
10 

1 1 The specification is objected to as failing to provide proper antecedent basis for 

12 the claimed subject matter. See 37 CFR 1.75(d)(1) and MPEP § 608.01 (o). Correction 

13 of the following is required: Claim 18 comprises the limitation "wherein the steps of 

1 4 generating, determining and fragmenting are performed independently of performing 

1 5 any steps on the data packet corresponding to a transport layer protocol and/or a 

1 6 network layer protocol". The specification fails to provide proper antecedent basis for 

17 this limitation. 
18 

1 9 Claim Rejections - 35 USC § 112 

20 

21 The following is a quotation of the first paragraph of 35 U.S.C. 112: 

22 The specification shall contain a written description of the invention, and of the manner and process of 

23 making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the 

24 art to which it pertains, or with which it is most nearly connected, to make and use the same and shall 

25 set forth the best mode contemplated by the inventor of carrying out his invention. 
26 
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1 Claims 18 and 19 are rejected under 35 U.S.C. 112, first paragraph, as 

2 failing to comply with the written description requirement. The claim(s) contains 

3 subject matter which was not described in the specification in such a way as to 

4 reasonably convey to one skilled in the relevant art that the inventor(s), at the 

5 time the application was filed, had possession of the claimed invention. See 

6 above objection to the specification. 
7 



8 The following is a quotation of the second paragraph of 35 U.S.C. 112: 

9 The specification shall conclude with one or more claims particularly pointing out and distinctly 
1 0 claiming the subject matter which the applicant regards as his invention. 

11 

12 Claims 18 and 19 are rejected under 35 U.S.C. 112, second paragraph, as 

1 3 being indefinite for failing to particularly point out and distinctly claim the subject 

14 matter which applicant regards as the invention. 

15 Regarding claim 18, the phrase "and/or" renders the claim indefinite because it is 



16 unclear whether the limitation(s) qualified by the phrase are part of the claimed 

17 invention. See MPEP § 2173.05(d). 
18 

1 9 Claim 1 9 is rejected by virtue of dependency. 

20 

21 
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Claim Rejections - 35 USC § 103 



2 



3 



The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 



4 obviousness rejections set forth in this Office action: 



5 
6 
7 
8 
9 

10 
11 



(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 



Claims 1-23 are rejected under 35 U.S.C. 103(a) as being unpatentable 



12 over IPSEC, "Minutes of IPSEC Working Group Meeting", in view of Kent et al. 

13 (Kent), "Fragmentation Considered Harmful". 



16 network transmission (i.e. NAT/Firewall traversal) (IPSEC, page 1 , #1) and the testing of 

1 7 the traversal of IKE packets over NAT devices, thus the generating and transmitting an 

1 8 IKE packet over a network (IPSEC, page 4, lines 1-7). IPSEC discloses that changes to 

1 9 the IKE protocol (to solve the IKE/NAT problem) are needed as packet fragmentation 

20 adversely affects IKE packets (IPSEC, page 4, par. 2; "Revised ESP", pars. 2, 3). 

21 IPSEC discloses as a solution that packets should be fragmented above UDP, resulting 

22 in multiple UDP packets - each packet encapsulating a fragment from the above and 

23 highest layer [application layer] where the IKE protocol stack operates (for evidence of 

24 protocol stacks, Applicant's representative may refer to the applicant's admitted Prior 

25 Art, fig. 4). Thus, IPSEC discloses fragmenting the IKE packet into a plurality of smaller 



14 



15 



Regarding claim 1, IPSEC discloses changes to the IKE protocol to support 
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1 packets and transmitting each of the plurality of smaller packets over a network (IPSEC, 

2 page 4, lines 1-7). 

3 IPSEC discloses that IKE packets should be fragmented before the UDP layer. 

4 However, IPSEC does not disclose specifically methods packet fragmentation, such as 

5 conditions requiring fragmentation and that a packet fragment should have a proper 

6 packet header. 

7 Kent et al. discloses principles for packet fragmentation. While Kent discusses 

8 these principals of packet fragmentation often in the context of the IP layer (Kent, pg. 

9 75, par. 4), Kent further discloses that these fragmentation methods are to be applied in 

10 higher protocol layers as well. Upper level protocol layers should be cognizant of 

1 1 fragmentation issues, and should fragment or send smaller packet sizes if the it is 

12 known that a larger packet size will be fragmented at the IP layer (Kent et al., section 3, 

1 3 par. 4). For example, Kent discloses that an upper layer (i.e. TCP) should not send a 

14 large un-fragmented segment when it a lower layer (i.e. IP) will have to fragment it 

15 (Kent, pg. 79, pars. 3, 4). 

16 Kent discloses that the packet fragmentation method consists of fragmenting a 

17 larger packet into a plurality of fragments. Each fragment is sent as a separate packet, 

1 8 with each of the plurality of smaller packets containing a properly formatted header 

19 according to the protocol (Kent et al., section 2.1). 

20 It would have been obvious to one of ordinary skill in the art to employ the 

21 principles for packet fragmentation disclosed by Kent with the teachings of IPSEC 

22 requiring the fragmentation of IKE packets above the UDP layer. This would have been 
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1 obvious because one of ordinary skill in the art would have been motivated to practically 

2 implement packet fragmentation methods for the purpose of fragmenting IKE packets 

3 above the UDP layer as required by IPSEC, so that the packets would not be improperly 

4 fragmented at the IP layer. The combination of IPSEC and Kent discloses that 

5 fragmented packets each have a proper header, and thus, it would have been obvious 

6 to one of ordinary skill in the art to follow this teaching as required by the combination of 

7 IPSEC and Kent when fragmenting IKE messages before they are passed to the UDP 

8 layer. 

9 Therefore, the combination of IPSEC and Kent et al. discloses: 

1 0 determining whether a response to the IKE packet was received and 

1 1 fragmenting the IKE packet into a plurality of smaller packets when a response is not 

12 received (Kent et al., section 3.3). To avoid improper fragmentation at the IP layer, the 

13 combination of IPSEC and Kent et al. discloses that a transmitting host would choose 

14 whether to fragment an IKE packet using received acknowledgements ("a response") of 

15 successful packet transmission. If the host does not receive an acknowledgment ("a 

16 response") then it will have to fragment it's transmitted packets into smaller packets until 

17 it receives a successful transmission acknowledgment, and accordingly discovers the 

1 8 proper fragment length for transmitting packets. 
19 

20 Regarding claim 2, the combination of IPSEC and Kent et al. discloses: 
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1 wherein each header includes an identifier that may be used to associate the 

2 smaller packet with a corresponding IKE packet (Kent et al., section 2, par. 4, lines 1-8; 

3 section 2.1, par. 2 ) 
4 

5 Regarding claim 3, it is rejected, at least, for the same reasons as claim 1 , and 

6 furthermore because the combination of IPSEC and Kent et al. discloses: 

7 a User Datagram Protocol (UDP) stack that is capable of generating UDP data 

8 packets for transmission over a network,(\PSEC; page 4, lines 1-8). IPSEC discloses 

9 the generation of multiple UDP packets and the fragmentation of IKE packets above 

10 UDP (thus, a UDP stack) for network transmission; 

1 1 an IKE protocol stack that generates IKE data packets that are subsequently 



1 2 processed by the UDP protocol stack (IPSEC; page 4, lines 1 -8). IPSEC discloses the 

13 generation and fragmentation of IKE packets (thus an IKE stack). The packets pass 

14 from a layer above UDP to a layer below UDP, and are fragmented above the UDP 

15 layer. 

1 6 and a fragmenter module that intercepts IKE data packets prior to being 

1 7 processed by to the UDP protocol stack and splits the IKE data packets into a plurality 

1 8 of smaller data packets that may be subsequently formatted by the UDP protocol stack 

19 (IPSEC, page 4, lines 1-8). IPSEC discloses fragmenting IKE packets (thus a 

20 fragmenter module) in a layer above the UDP layer (thus intercepting IKE packets prior 

21 to being processed by the UDP stack). 
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1 wherein, each of the plurality of smaller data packets includes a header formatted 

2 according to the IKE protocol (see rejection of claim 1 ). 
3 

4 Regarding claim 4, the combination of IPSEC and Kent et al. discloses: 

5 generating an IKE data packet; intercepting the IKE data packet before it is 

6 passed to a subsequent network protocol stack (see rejection of claim 3); 

7 determining a maximum size for fragments of an IKE data packet (Kent et al., 

8 section 3.3, par. 2). 

9 dividing the IKE data packet into at least two smaller packets; and prepending a 



1 0 header to each smaller packet, wherein each header for each smaller packet includes 

1 1 an identifier that associates the smaller packet with its corresponding IKE data packet 

1 2 (see rejection of claim 1 ). 
13 

14 Regarding claim 5, the combination of IPSEC and Kent et al. discloses: 

1 5 wherein the dividing step is performed such that the combined size of each 

1 6 smaller packet and prepended header will not exceed the maximum size (Kent et al., 

17 section 3.3, par. 2). The combination of IPSEC and Kent et al. discloses that the 

18 datagram size is chosen so that the fragmented packet (data + header) will not be 

19 fragmented ("will not exceed the maximum size"). 
20 

21 Regarding claim 6, the combination of IPSEC and Kent et al. disclose: 

22 receiving a plurality of fragments of an IKE data packet from a transmitting node, 
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1 wherein each fragment includes an identifier that associates each fragment with an IKE 

2 data packet ; and discarding all fragments that contain a first identifier if a 

3 predetermined number of fragments are received that contain a second identifier (Kent 

4 et al., section 2.4, par. 3). 
5 

6 Regarding claim 7, the combination of IPSEC and Kent et al. disclose: 

7 wherein the step of discarding all fragments that contain a first identifier is 

8 performed when at least one fragment is received that contains a second identifier (Kent 

9 et al., section 2.4, par. 3). 
10 

1 1 Regarding claim 8, the combination of IPSEC and Kent et al. disclose: 

1 2 determining whether all fragments that are associated with an IKE data packet 

1 3 have been received, and sending a no acknowledgment (NAK) message to the 

1 4 transmitting node when at least one fragment has not been received (Kent et al. , section 

1 5 3.3.3). A receiving host is disclosed as making a determination as to whether all 

16 fragments associated with an IKE packet has been received. The receiving host will 

17 convey a "Time exceeded" message ("NAK") to the transmitting host when at least one 

1 8 fragment has not arrived, indicating to the transmitting host that it has not received all 

19 the fragments. 
20 

21 Regarding claim 9, the combination of IPSEC and Kent et al. disclose: 
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1 determining the total size of all fragments that contain the same identifier and 

2 discarding said fragments when the total size exceeds a predetermined limit (Kent et al., 

3 section 2.4, par. 3). 
4 

5 Regarding claim 10, the combination of IPSEC and Kent et al. does not disclose 



6 wherein the predetermined limit is 64 kilobytes. This, however, would have been 

7 obvious to one of ordinary skill in the art to set a predetermined limit of 64 kilobytes as 

8 the total size of all possible fragments. As evidenced by the "Glossary for the Linux 

9 FreeS/WAN project" - (definition for DoS), this would have been obvious to one of 

10 ordinary skill in the art because the standardized size limit of an IP packet is 64 

1 1 kilobytes, and a failure to discard illegitimate packets when the size exceeds the 

12 standard limit would result in denial of service attacks. 
13 



14 Regarding claim 1 1, it is rejected, at least, for the same reasons provided for the 

1 5 rejection of claims 1 and 2. 
16 

17 Regarding claim 12, the combination of IPSEC and Kent et al. disclose: 

1 8 further comprising means for determining the capability of the receiver node for 

1 9 receiving fragmented packets (Kent et al., section 3.3, par. 2). 
20 

21 Regarding claims 13, 14, and 15 they are rejected, at least, for the same reasons 

22 as claims 1 and 2. 
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1 

2 Regarding claim 16, the combination of IPSEC and Kent et al. disclose: 

3 wherein the plurality of smaller packets contain the same information as that 

4 contained within the original IKE packet (Kent et al., section 2.4, par. 3, section 2.1). 
5 

6 Regarding claim 17, the combination of IPSEC and Kent et al. disclose: 

7 wherein at least one of the plurality of smaller packets contains the header 



8 formatted according to the IKE protocol (Kent et al., section 2.1). As disclosed by the 

9 combination of IPSEC and Kent et al., fragmentation involves fragmenting the original 

10 packet into smaller packets, each containing the protocol and header fields of the 

11 original packet. 
12 

1 3 Regarding claim 1 8, it is rejected, at least, for the same reasons as claim 1 , and 

14 furthermore because the combination of IPSEC and Kent discloses: 

1 5 wherein the steps of generating \ determining and fragmenting are performed 

16 independently of performing any steps on the data packet corresponding to a transport 

17 layer protocol and/or a network layer protocol (IPSEC, page 4, lines 6-8). The 

18 combination of IPSEC and Kent discloses generating and fragmentation (accordingly 

19 determination to fragment) as occurring before the lower protocol layers. 
20 

21 Regarding claim 19, the combination of IPSEC and Kent et al. disclose: 
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1 wherein the step of determining whether fragmentation is necessary is not based 

2 exclusively on the size of the data packet (Kent et al., section 2, par. 3, lines 1-6; 

3 section 3, pars. 1 - 6). The combination of IPSEC and Kent et al. disclose the step of 

4 determining whether fragmentation is necessary is based upon the size of the data 

5 packet + overhead size. 
6 

7 Regarding claims 20 and 21, they are rejected, at least, for the same reasons as 

8 claim 1 , and further because the combination of IPSEC and Kent et al. disclose: 

9 fragmenting the packet into a plurality of fragments using a code module that 

1 0 does not implement the TCP, UDP or IP protocols before the packet is processed by a 

1 1 code module that does implement the TCP, UDP or IP protocols (IPSEC; page 4, lines 

12 1-8; Kent et al., section 3). The combination of IPSEC and Kent et al. disclose the 

13 fragmentation of IKE packets above the UDP layer - this would include TCP (parallel to 

14 UDP) and IP (below UDP). The fragmentation is computer based and therefore 

1 5 inherently performed by some type of module for instructing a computer ("code 

16 module"). 



1 7 comprising including an identifier that identifies the data packet in eah packet 

1 8 fragment (see rejection of claim 2); and transmitting the packet fragments over a 

1 9 network (see rejection of claim 1 ). 
20 

21 Regarding claim 22, the combination of IPSEC and Kent et al. disclose: 



Application/Control Number: 10/056,889 Page 13 

Art Unit: 2137 

1 receiving a plurality of data packets containing Internet Key Exchange (IKE) 

2 information, wherein the packets were transmitted from a transmitting node in a order 

3 that can be determined from information contained within the received data packets 

4 (Kent et al.; section 2.1, par. 3; section 2.4, par. 3); 

5 determining from information contained within the received data packets whether 

6 any of the received packets have been received in an order that differs from the order in 

7 which the packets were transmitted from the transmitting node (Kent et al.; section 2.1 , 

8 par. 3; section 2.4, par. 3); 

9 and discarding at least certain of the received packets when a predetermined 

10 number of out of order packets have been received (Kent et al.; section 2.1 , par. 3; 

1 1 section 2.4, par. 3). 
12 

1 3 Regarding claim 23, the combination of IPSEC and Kent et al. do not specifically 

14 disclose the step of sending a message to the transmitting node that out of order 

1 5 packets have been received. The combination does disclose the sending of a message 

16 to the transmitting node so as to acknowledge that the packets have been received in 

17 order (Kent et al.; section 2.1 , par. 3; section 2.4, par. 3). It would have been obvious to 

18 one of ordinary skill in the art, based upon logical reasoning, to also send a message 

19 acknowledging that the packets were not received in order. This would have been 

20 obvious because one of ordinary skill in the art would have been motivated to alert the 

21 system when transmission errors occur, so as to facilitate the operation of the system. 
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1 Response to Arguments 

2 

3 Applicant's arguments filed 4/7/06 have been fully considered but they are not 

4 persuasive. 

5 Applicant's arguments with respect to claim 3 have been considered but are moot 

6 in view of the new ground(s) of rejection. 
7 

8 Applicant's representative argues primarily that: 

9 

10 (i) The combination of IPSEC and Kent is Improper because: 

1 1 However, not only does Kent not disclose IP layer fragmentation at upper level 

1 2 protocol layers, but it discloses the very opposite, that fragmentation should be 

1 3 performed at the IP datagram layer, i.e., the network layer (i.e., layer 3 or IP layer) of 

14 the networking protocol framework. (Remarks, pg. 8) 

15 ... Kent does disclose or suggest fragmentation avoidance above the IP layer at 

1 6 upper level protocol layers, but it discloses the very opposite, that fragmentation should 

17 be performed at the IP datagram layer, i.e., the network layer (i.e., layer 3 or IP layer) of 

1 8 the networking protocol framework: 

19 In response, the examiner finds the arguments of the applicant's representative 

20 to be unpersuasive and a mischaracterization of the prior art. Kent does in fact 

21 discloses fragmentation at upper protocol levels (applicant's representative is 

22 respectfully encouraged to review the reference of Kent and the rejection of claim 1). 
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1 Furthermore, the examiner points out that the reference of Kent discloses 

2 principles of packet fragmentation and fragmentation avoidance and the reference of 

3 IPSEC discloses packet fragmentation avoidance via packet fragmentation of IKE 

4 packets above the IP layer (above the UDP layer). In response to applicants argument 

5 that there is no suggestion to combine the references, the examiner recognizes that 

6 obviousness can only be established by combining or modifying the teachings of the 

7 prior art to produce the claimed invention where there is some teaching, suggestion, or 

8 motivation to do so found either in the references themselves or in the knowledge 

9 generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071 , 5 

10 USPQ2d 1596 (Fed. Cir. 1988)and In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. 

1 1 Cir. 1992). In this case, the examiner respectfully asserts that not only is motivation 

12 found within logical reasoning by those of ordinary skill in the art (i.e. rational thought 

13 dictates that a teaching to fragment packets would encourage one to make practical 

14 application of this teaching), but also within the prior art references (i.e. IPSEC 

15 discloses to fragment at an upper level layer and Kent discloses that fragmentation 

16 avoidance principles are applicable in an upper level layer). 
17 

1 8 (ii) Accordingly, even if IPSEC and Kent were combined, the combination would not 

1 9 disclose or suggest a method for transmitting IKE data packets across a network 

20 comprising, inter alia, fragmenting the IKE packet into a plurality of smaller data packets 

21 when a response is not received. (Remarks, pg. 9) 
22 
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1 In response, the examiner respectfully encourages the applicant's representative 

2 to review the rejection of claim 1 , wherein the examiner shows that the combination of 

3 IPSEC and Kent discloses fragmentation when "a response" is not received. 
4 

5 (iii) Neither IPSEC nor Kent disclose or suggest the concept of an IKE data packet. 

6 (Remarks, pg. 11) 
7 

8 In response, the examiner respectfully asserts that the prior art discloses IKE 

9 data packets (IPSEC, page 4, par. 2; "Revised ESP", pars. 2, 3; page 4, lines 1-8). 

10 Herein the context of IPSEC discloses the fragmentation of IKE messages [i.e. packets 

1 1 bearing the certificate payload]. Furthermore, IPSEC discloses that additional problems 

12 resulted from the improper utilization by devices of the IKE cookie states (data found 

13 within the headers of IKE packets - applicant's representative may refer to the 

14 applicant's submitted prior art " (Harkins et al., "The Internet Key Exchange Protocol"). 



15 In addition to the above, the examiner respectfully encourages the applicant's 

16 representative to review the admission of the applicant's themselves regarding the 

17 disclosure of the prior art - namely that IPSEC in fact does disclose or suggest IKE data 

18 packets [Remarks, pg. 8 - emphasis added]: 

1 9 7Psec deals with a variety of issues relating to the above charter, including 

20 changes to IKE to support Network Address Translation (NAT) Firewall traversal. 

21 (Page 1) 

22 IPSEC indicates that the testing of IPsec over NA T revealed some problems, 
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1 including certificate fragmentation. (Page 3, last line - page 4, line 6). Possible 

2 approaches to avoid fragmentation were considered, including fragmenting packets 

3 at a layer of the networking protocol framework that is above the transport layer at 

4 which the User Datagram Protocol (UDP) protocol resides. (Page 4, lines 8-10)". 
5 

6 (iv) . . . IPSEC merely discloses that fragmentation of a data packet may occur at a 

7 layer above the transport layer of a networking protocol framework, but provides no 

8 description of how this fragmentation occurs. 

9 Nor does Kent disclose the concept of an IKE data packet. (Remarks, pg. 11) 
10 

1 1 In response to applicant's arguments against the references individually, one 

12 cannot show nonobviousness by attacking references individually where the rejections 

1 3 are based on combinations of references. See In re Keller, 642 F.2d 41 3, 208 

14 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 

15 1986). 
16 

1 7 (v) As discussed in previous sections, neither PSEC nor Kent disclose or suggest 

1 8 the concept of an IKE packet, nor generating one, attempting whether it was 

1 9 successfully received, or fragmenting one into smaller packets. (Remarks, pg. 13) 
20 
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1 In response, the examiner presumes the applicant's representative to mean 

2 "determining whether it was successfully received", as "attempting whether it was 

3 successfully received" does not resemble any claim limitation. 

4 In addition, the examiner respectfully encourages the applicant's representative 

5 to review the above claim rejections, responses to arguments, and the prior art, as the 

6 concept of an IKE packet, generation of one, determining the successful transmission of 

7 a packet, and packet fragmentation are all issues that have been previously discussed. 
8 

9 (vi) . . . Kent does not disclose fragmenting any type of packet into a plurality of 

1 0 smaller packets when a response is not received (Remarks, pg. 1 4) 
11 

12 In response, the examiner respectfully encourages the applicant's representative 

13 to review the above claim rejections (claim 1), responses to arguments (ii), and the prior 

14 art, as the concept of fragmentation when "a response" is not received has been 

15 previously discussed. 
16 

1 7 (vii) . . . IPSEC does not disclose or suggest determining whether fragmentation of a 

1 8 data packet is necessary to successfully transmit IKE information over a network. 

1 9 Accordingly, even if IPSEC and Kent were combined, the resulting combination would 

20 not teach or suggest performing the steps of generating, determining and fragmenting 

2 1 independently of performing any steps corresponding to a transport layer protocol 

22 and/or a network layer protocol. (Remarks, pg. 15). 
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1 

2 In response to the arguments regarding the limitations added in amendment of 

3 claim 1 8, the examiner respectfully directs the attention of the applicant's representative 

4 to the rejection of claim 1 8. 

5 Furthermore, in response to applicant's argument that the references fail to show 

6 certain features of applicant's invention, it is noted that the features upon which 

7 applicant relies (i.e., determining whether fragmentation of a data packet is necessary to 

8 successfully transmit IKE information over a network) are not recited in the rejected 

9 claim(s). Although the claims are interpreted in light of the specification, limitations from 

1 0 the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1 1 81 , 26 

11 USPQ2d 1057 (Fed. Cir. 1993). 
12 

13 (viii) Accordingly, even if IPSEC and Kent were combined, the resulting combination 

14 would not employ a method of resolving transmitting errors that comprises, inter alia, 

1 5 including an identifier that identifies the data packet in each packet fragment. 

16 (Remarks, pg. 17). 
17 

1 8 In response, the examiner respectfully encourages the applicant's representative 

19 to review the above claim rejections, as the concept of including an identifier within a 

20 packet has been previously discussed. 
21 
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1 (ix) Thus, Kent does not teach or suggest discarding received packets when a 

2 predetermined number of out-of-order packets have been received. PSEC fails to 

3 remedy this deficiency of Kent. (Remarks, pg. 17) 
4 

5 In response, the examiner respectfully encourages the applicant's representative 

6 to review the above claim rejections and the prior art. Specifically, Kent discloses 

7 receiving a predetermined number [the amount available to buffer] of out of order 

8 packets (Kent, section 2.4, par. 3) and Kent discloses discarding at least certain of the 

9 received packets (Kent, section 2.4, par. 3). The examiner points out that the section 

10 (2.1 , par. 3) of Kent was intended to simply show that packets have sequence numbers 

1 1 enabling the system to determine packet ordering. The examiner takes note that the 

12 applicant's representative appears to have presumed paragraph 3 of section 2.1 to refer 

13 to the second bulleted section of paragraph 1 . The examiner had interpreted paragraph 

14 3 as being the paragraph beginning with "Higher level protocols...". 
15 

16 Conclusion 



17 



18 



The prior art made of record and not relied upon is considered pertinent to 



19 



applicant's disclosure. 



20 



See Notice of References Cited 



21 



Application/Control Number: 10/056,889 Page 21 

Art Unit: 2137 

1 Applicant's amendment necessitated the new ground(s) of rejection presented in 

2 this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP 

3 § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 

4 CFR 1.136(a). 

5 A shortened statutory period for reply to this final action is set to expire THREE 

6 MONTHS from the mailing date of this action. In the event a first reply is filed within 

7 TWO MONTHS of the mailing date of this final action and the advisory action is not 

8 mailed until after the end of the THREE-MONTH shortened statutory period, then the 

9 shortened statutory period will expire on the date the advisory action is mailed, and any 

10 extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 

1 1 the advisory action. In no event, however, will the statutory period for reply expire later 

1 2 than SIX MONTHS from the date of this final action. 

1 3 Any inquiry concerning this communication or earlier communications from the 

14 examiner should be directed to Jeffery Williams whose telephone number is (571) 272- 

1 5 7965. The examiner can normally be reached on 8:30-5:00. 

1 6 If attempts to reach the examiner by telephone are unsuccessful, the examiner's 

17 supervisor, Emmanuel Moise can be reached on (571) 272-3865. The fax phone 

1 8 number for the organization where this application or proceeding is assigned is 571- 

19 273-8300. 
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Information regarding the status of an application may be obtained from the 



2 Patent Application Information Retrieval (PAIR) system. Status information for 

3 published applications may be obtained from either Private PAIR or Public PAIR. 

4 Status information for unpublished applications is available through Private PAIR only. 

5 For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 

6 you have questions on access to the Private PAIR system, contact the Electronic 

7 Business Center (EBC) at 866-217-91 97 (toll-free). If you would like assistance from a 

8 USPTO Customer Service Representative or access to the automated information 

9 system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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